comments

diff --git a/doc/bugs/Web_app_terribly_slow/comment_3_1850a8f1a1c30ab8665fc5b777a89cf9._comment b/doc/bugs/Web_app_terribly_slow/comment_3_1850a8f1a1c30ab8665fc5b777a89cf9._comment
new file mode 100644 (file)
index 0000000..0c2be50
--- /dev/null
+++ b/doc/bugs/Web_app_terribly_slow/comment_3_1850a8f1a1c30ab8665fc5b777a89cf9._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2024-12-03T18:41:08Z"
+ content="""
+Tried in chromium, also seeing it block sometimes, though not always, on
+page loads.
+
+This seems rather similar to this old bug involving the same software:
+<https://github.com/yesodweb/wai/issues/146>
+But not I think quite the same, because that was caused by
+a long delay between clicks, and this happens when clicking immediately.
+
+The browser's network console shows a few ms for all resources to load,
+except the page itself which for some reason takes a log time.
+
+tcpdump shows that chromium does not send a request for that page until
+many seconds after the click. The response to the request is immediate.
+
+Before that point there is only some SYN/ACK traffic. Which looked a bit
+weird maybe.
+"""]]

diff --git a/doc/bugs/Web_app_terribly_slow/comment_4_bbde0af9e43dc14c779fa8e7b3969edd._comment b/doc/bugs/Web_app_terribly_slow/comment_4_bbde0af9e43dc14c779fa8e7b3969edd._comment
new file mode 100644 (file)
index 0000000..3459cf5
--- /dev/null
+++ b/doc/bugs/Web_app_terribly_slow/comment_4_bbde0af9e43dc14c779fa8e7b3969edd._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2024-12-03T20:13:35Z"
+ content="""
+Looking at the network inspector, it seems more likely a given click stalls
+when there are multiple long polling requests ongoing at the same time
+(which show as "pending").
+
+So on a hunch, I disabled javascript in chromium. No more hangs.
+
+I suppose maybe chromium has a small pool of connections to the web server,
+and if all of those get blocked up doing long polling, and if it doesn't
+cancel those when navigating away from the page that made the long polling
+request, it could block?
+
+But why wouldn't it cancel them? The requests were made by the page it's
+navigating away from. Maybe it cancels them only once it's loaded the new
+page.
+
+I do think that's it though. When I open 2 tabs both to the webapp, 
+a request in one tab can be stalled, and pressing escape in the other tab,
+when it cancels the long polling requests, will unstall it.
+
+Amazingly, chromium is limited to 6 concurrent connections per server, with
+no way to configure it! And the front page of the webapp opens several
+long polling connections.
+
+In firefox, by comparison, the network inspector shows the long polling
+connections apparently disappear when navigating to a new page. But, there
+is a similar problem, when opening 2 tabs to the webapp, one can stall,
+due to the long polling connections open by the other tab.
+
+So, I think the solution to this will either need to involve some change
+to the long polling javascript, if there is some way to make chromium
+cancel the request when navigating away... Or it would need to replace the
+long polling with something else entirely.
+"""]]